문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 게임 개발자 (문단 편집) === [[QA#s-2|QA 엔지니어/테스터 직군]] === [include(틀:다른 뜻1, other1=전반적인 QA업무 프로세스, rd1=QA)] '''Quality Assurance'''. 게임의 품질을 평가하는 역할. 즉 올바른 방식으로 제작되고 있는지 확인한다. 게임에 있어서 전반적인 지향점에 대한 충실도를 평가하고 부족한 점이나 버그 및 태스크를 관리 보고하는 것을 주 업무로 한다. 또는 문제점을 개발자와 함께 해결하기도 한다. 게임 산업 초기에는 개발자가 모든 테스트를 담당했다. 이 때는 게임의 규모가 제한되기 때문에 하나 또는 두 명 이상의 테스터는 필요하지 않았다. 게임이 더욱 복잡해짐에 따라 개발자가 모든 테스트를 담당할 수 없게 되자 QA라고 불리는 더 큰 리소스 풀이 필요해져서 탄생한 직군이다. 인게임 내 UI 편의성을 분석하는 것이 대표적인 예이고, 어디 구석에서 점프 수백 번 뛰기 같은 기기묘묘한 테스트를 하는 경우도 있다. 예상치 못한 커맨드 입력, 반복 작업으로 인해 프로그램이 꼬여 버그가 일어나는 경우가 많기 때문이다. 문서 보고에 통달한 알파 테스터로 불리기도 하는데, 실제로 각 회사에서 작성된 기획서를 기반으로 게임의 기본적인 동작, 각종 컨텐츠 등을 체크리스트 및 테스트 케이스 문서를 작성하여 테스트를 진행하는 프로세스를 주로 업무하는 편이다. 근래 대부분의 회사 및 대규모 개발 그룹에서는 버그 리포팅 기능을 체계화 해 운영하고 있다. 이들은 게임 업계 전반적으로 매우 낮은 대우에도 불구하고 프로 의식이 투철하다 못해 개발자가 예상치 못한 기괴한 조작, 조합까지 시도한다. 게이머가 하면 [[뻘짓]]이지만, 이 기괴한 조합에서 치명적인 버그가 발생하는 경우도 적잖으므로 누군가 해 봐야 하는 문제이기도 하다. 이 과정에서 예기치 않게 겪고 본 것들을 취합해 개발자가 인지하고 수정할 수 있도록 [[육하원칙]] 하의 명쾌한 DB 리포트를 작성해 제출한다. 이 부분이 일반인으로 구성된 배타 테스터와의 차이점이다. 하지만 [[베타 테스터]]는 전문성이 없을지 몰라도 나름대로 의미가 큰데, 다양한 기기환경에 따른 프로그램 구동 정보를 수집할 수 있는데다, 비전문적일지언정 투입할 수 있는 인시(人時)의 규모가 급이 다르며, 비전문가답게 굉장히 다양한 시도를 해 보기 때문이다. 하지만 회사 입장에선 플레이는 누구라도 시킬 수 있다는 인식도 존재하는 것이 현실이므로, 국내 중소 제작사에서는 QA가 없이 베타 테스트를 빡세게 굴리는 경우도 많다. 그래도 체계화된 중소기업에선 QA는 채용하는 편인데, 왜냐하면 체계적으로 개선사항을 정리해 제출하는 것과 개발진이 자기들이나 유저 데이터를 토대로 찾아내는 것은 그 촘촘함의 정도가 많이 다르기 때문이다. 게다가 개발진들은 '''자기네 작품을 질리도록 하다 보니''' 아무리 조작이나 인터페이스, 레벨이 극악해도 이에 익숙해 문제점을 자각하지 못하는 경우도 많다. 이런 상황의 대표적 예시가 [[마그나카르타 눈사태의 망령]], [[포가튼 사가]]로, 이쪽은 버그도 버그대로 못 잡았지만 난이도 밸런싱도 문제가 상당히 있는 편이다. [[울티마 8]] 역시 높은 난이도의 점프 액션 때문에 엄청 욕을 먹다가 후에 패치되었다. 당시 전문 테스터라는 개념이 없었던 시대라 이를 개발자들이 반복 플레이로 맡았는데, 문제는 이를 반복하다 보니 다들 점프 컨트롤에 익숙해져서 아무도 그게 극악의 난이도라는 걸 인식 못 한 채 그대로 출시되어 욕을 먹었다. 세간에서는 게임 QA를 '''돈 주고 게임하는 직업'''이라는 인식도 있다. 사내의 임원과 개발팀 주변에서 안 좋은 인식으로 취급하는 업종이기도 한데, 원래 기업규모, 산업분야 관련없이 [[품질관리(직무)|품질관리]]를 도맡은 팀은 다른 팀과 사이가 안 좋은 것이 일반적이다. 게임에서 버그를 잡아내는 것은 공장에서 불량품을 잡아내는 것과 그 성질상 동일하다 할 수 있는데, 불량품이 나오면 당연히 생산을 줄이고 유지보수에 인력을 써야 한다. 개발과 제작, 곧 '''생산량이 곧 실적인''' 현장팀 입장에서 생산력을 저하하게 만드는 것처럼 보이는 품질관리팀을 싫어하는 것은 당연할 수 밖에 없다. 2000년대까진 QA의 대부분은 본사의 정직원으로 두었으나 이제는 그런 경우는 많지 않고 인건비 절감과 인력수급의 유연성을 위해 아웃소싱을 통한 외주 업체 및 자회사를 분리하여 운영하는 곳이 상당히 많아졌다. 그렇게 개발사와 QA가 별도로 업무하는 형태를 퍼블리싱 QA라고 부른다. 게임 테스트에 두각을 나타내 발탁해 기획을 맡겨봤다든가 하는 일화같은 옛날 이야기나 게임 업계에 취직을 할려고 발 담그는 식으로 게임 QA에 우선적으로 입사를 하여 연차를 채운 후 기획이나 다른 직군으로 전향하는 경우가 많았지만 요즘은 어렵다. 요즘은 아웃소싱 QA는 외주로 맡겨버리는 것이 트렌드지만 개발팀과 밀접하게 업무하는 QA들을 개발 QA라고 부르며 많은 개발사에서는 여전히 QA를 가지고 있긴 하다. [[온라인 게임]]과 [[모바일 게임]] 시장이 발달된 국내는 게임 운영을 최일선에서 책임지기도 하기에[* 그래서 시정이 잘 이루어지는 곳은 개발부서인 기획자나 프로그래머와 직접적인 소통이 많은 편이다.] 실제로 커뮤니케이션을 통해서 개발자가 QA에게 버그 및 이슈를 재현을 해달라고 요청하는 편이 빈번한데 이 때문에 테스트 엔지니어로보단 [[GM]] 같은 인식으로 보는 편이다. 3N같은 대형 게임사를 제외하면 게임사 전반의 임금 자체가 높지 않고 딱히 직업적 대우도 없다 보니 더욱 편견이 심한 편인데다, 사실 온라인 게임에서는 테스트를 오픈/클로즈 베타로 대강 처리하는 경우가 많기 때문이다. 각 회사마다 QA를 운영하는 프로세스는 상이하나 기본적으로 게임 개발의 QA는 기획, 아트, 프로그램 파트 부서에서 작업 진행 중인 문서나 빌드 상태를 파악하여 체크리스트 또는 테스트 케이스 문서를 작성한다. 해당 문서를 기반으로 추후 테스트를 진행 시 프로세스를 돌아가게 하게끔 개발자보다 더 자사의 게임을 꿰뚫고 있어야 한다. 안 그러면 다른 부서에서는 'QA는 일 안 하고 놀고만 있냐?'하면서 비아냥 대거나 무시하기 마련이다. 라이브 서비스 중인 온라인 게임이나 모바일 게임에서 QA의 역할은 업데이트 주기에 서버 점검 진행 시 오픈 시간 내에 테스트를 진행하여 게임의 기본 동작 여부 확인 및 신규 컨텐츠 적용 확인, 업데이트 내역 등을 확인하여 문제 없이 잘 적용되었는지 파악하여 QA에서 테스트 완료 사인을 내려야 서버 점검 시간 내에 패치를 적용하여 새로운 빌드를 업데이트를 하게된다. 만약 여기서 버그가 발견되거나 누락된 문제가 발생된다면 점검이 길어지고 위에서는 내리갈굼이 일어나는 것이 빈번하다. * 체크리스트 (Checklist) 테스트를 하기 위한 검증 항목들을 '''통과/실패'''로 답을 할 수 있도록 나열한 테스트의 방식이다. 게임에서 동작하는 결과 따라 체크리스트에서 작성된 '''기대결과'''에 맞게 행동을 하게되면 통과, 결과가 다르게 나오면 실패로 체크를 하여 테스트의 기본적인 체크 방식을 말한다. (ex: 바탕화면 아이콘 실행 시 정성적으로 클라이언트가 구동되는 것을 확인) 체크리스트에서는 기본적으로 검증이 완료된 테스트 항목을 QA에서 지속적으로 빌드 안정성을 테스트를 하기 위해 자주 사용된다. TC와 유사한 부분이 많지만 TC는 컨텐츠 단위로 신규 작업물을 검증하는 단계인 반면 체크리스트는 앞서 말하듯 안정성 테스트에 기본적인 검증 항목을 체크하는 차이다. * 테스트 케이스 (Test Cace) 특별한 목표 및 테스트 진행을 해야될 상황에서 테스팅을 하기 위한 입력 값, 실행 사전조건, 예상 결과, 실행 사후 조건들의 집합. 특별한 목표와 테스트 상황은 특정 프로그램 경로를 실행하거나 지정된 요구 사항을 준주하는지 검증하는 단계를 말한다. 해당 단계에서는 QA는 기획실에서 제작된 기획서를 기반으로 기획서에 명시되어 있는 행동과 결과를 토대로 QA는 TC를 작성한다. 기획서가 완성되었다고 해서 안심을 할 부분이 아니라 기획서가 업데이트 되거나 개발실에서 구현 불가로 기획서의 일부가 개발 지연 또는 개발에서 제외하게 되기 때문에 항시 기획서를 업데이트가 되었는지 확인하면서 작성을 하게된다. 개발실에서 완료가 된 후 QA가 테스트를 진행하는 빌드에서 컨텐츠가 적용되었을 때 작성하게 된 TC를 테스트 진행하게 된다. 테스트 진행하다가 기능 동작되지 않거나 기획서에 없던 내용이 발생될 경우 테스트 항목에 코멘트를 작성하여 결과 시트에 동작이 안 되어서 실패되거나 테스트 불가하여 진행 못하는 항목 등을 결과 문서에 정리를 하여 기획자에게 완료된 TC 문서를 공유한다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기